home *** CD-ROM | disk | FTP | other *** search
/ kermit.columbia.edu / kermit.columbia.edu.tar / kermit.columbia.edu / newsgroups / misc.20020314-20021006 / 000084_fdc@columbia.edu_Mon May 20 18:04:59 EDT 2002.msg < prev    next >
Text File  |  2002-10-06  |  3KB  |  74 lines

  1. Article: 13378 of comp.protocols.kermit.misc
  2. Path: newsmaster.cc.columbia.edu!news.columbia.edu!news-not-for-mail
  3. From: fdc@columbia.edu (Frank da Cruz)
  4. Newsgroups: comp.protocols.kermit.misc
  5. Subject: Re: REGET not as clever as RESEND?
  6. Date: 20 May 2002 18:04:44 -0400
  7. Organization: Columbia University
  8. Lines: 57
  9. Message-ID: <acbrts$1c7$1@watsol.cc.columbia.edu>
  10. References: <acbqst$bj2$1@panix3.panix.com>
  11. NNTP-Posting-Host: watsol.cc.columbia.edu
  12. X-Trace: newsmaster.cc.columbia.edu 1021932286 17489 128.59.39.139 (20 May 2002 22:04:46 GMT)
  13. X-Complaints-To: postmaster@columbia.edu
  14. NNTP-Posting-Date: 20 May 2002 22:04:46 GMT
  15. Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:13378
  16.  
  17. In article <acbqst$bj2$1@panix3.panix.com>,
  18. David Combs <dkcombs@panix.com> wrote:
  19. : RESEND does a pretty good job of almost instantly
  20. : recovering up to the %done that it had been
  21. : at when the prior transfer crapped out.
  22. : REGET seems to me so far to do a much POORER
  23. : job of doing that, like recovering up to only
  24. : maybe 1/3 of how far the prior get had gotten,
  25. : and then rereading a whole lot of stuff that
  26. : had (presumably) already been read in the prior
  27. : kermit-run.
  28. : Am I the only one who has seen this?
  29. It doesn't ring a bell.  Are you saying it corrupts
  30. the file, or just takes longer to resynchronize before
  31. resuming the download?
  32.  
  33. : (NOTE: I was using -i)
  34. : QUESTION: what is the SIZE of the blocks
  35. : that kermit sends?  (by default)
  36. The sender sends blocks (packets) of whatever length
  37. the receiver tells it to.  SHOW PROTOCOL at the
  38. receiver, see the receive packet length.
  39.  
  40. : Now, kermit registers 100%, but starts getting
  41. : errors (two per second) trying to get the last
  42. : several bytes, it seems.
  43. That doesn't have anything to do with RESEND or REGET.
  44. If it happens, it's because of transmission errors,
  45. which could happen with any kind of file transfer.
  46.  
  47. Is this a straight dialup connection or a Telnet
  48. connection or what?
  49.  
  50. If straight dialup, what kind of modem?  What serial
  51. speed?  Are you using RTS/CTS (hardware) flow control?
  52.  
  53. If Telnet, the same questions about the underlying PPP
  54. driver.
  55.  
  56. What version of Kermit do you have on your end? (Panix
  57. has the latest, 8.0.201, on its end, at least if we're
  58. talking about the same Panix).
  59.  
  60. Just now I tried downloading a 3MB file from Panix,
  61. interrupting the download, REGET'ing the file, and
  62. repeating the process several times until it was fully
  63. downloaded.  There were no delays, no errors, no
  64. failures.  This was using Kermit 95 1.1.21 as a
  65. client.
  66.  
  67. - Frank
  68.